app/main.py (1)

1562-1571: Consider extracting duplicate JSON parsing logic.

The fleet summary duplicates the JSON parsing and count logic that _parse_worker_json() already handles. Consider reusing it:

Suggested refactor

     for w in workers:
-        sys_info = json.loads(w.get("system_info", "{}"))
-        is_android = sys_info.get("device_type") == "android"
-        if is_android:
-            apps = json.loads(w.get("apps", "[]"))
-            total_containers += len(apps)
-            total_running += sum(1 for a in apps if a.get("running"))
-        else:
-            containers = json.loads(w.get("containers", "[]"))
-            total_containers += len(containers)
-            total_running += sum(1 for c in containers if c.get("status") == "running")
+        _parse_worker_json(w)
+        total_containers += w["container_count"]
+        total_running += w["running_count"]
         if w["status"] == "online":
             online_workers += 1

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/main.py` around lines 1562 - 1571, The code duplicates JSON parsing and
counting for workers; instead call the existing helper _parse_worker_json(w) (or
adapt it to return both a list of containers/apps and the running count) and use
its outputs to increment total_containers and total_running; replace the
sys_info/json.loads blocks and the is_android branch with a single call to
_parse_worker_json(w) and then do total_containers += len(containers) and
total_running += running_count (or derive running_count from the returned
containers), ensuring _parse_worker_json handles both "apps" and "containers"
and returns a consistent structure.

app/database.py (1)

181-185: Consider logging when migration adds the new column.

The migration silently adds the apps column. Adding a log statement would help operators understand schema changes during upgrades.

Suggested improvement

         if "apps" not in cols:
             await db.execute("ALTER TABLE workers ADD COLUMN apps TEXT NOT NULL DEFAULT '[]'")
+            _logger.info("Migrated workers table: added 'apps' column")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/database.py` around lines 181 - 185, The migration silently adds the apps
column; update the block that checks PRAGMA table_info(workers) and executes
ALTER TABLE workers ADD COLUMN apps ... to emit a log entry when the column is
added. Use the project's existing logger (e.g., logger or process_logger) and
log at info/debug level with a clear message like "Added 'apps' column to
workers table during migration" and include the default value and SQL executed;
keep the log right after the await db.execute(...) that adds the column so
operators can see schema changes.

app/templates/fleet.html (1)

142-147: Inconsistency with fmtNetBytes in app.js — missing null guard.

Line 143 returns b + ' B' which would produce "undefined B" or "null B" if called with falsy non-zero values. The equivalent function in app/static/js/app.js:77 uses (b || 0) + ' B'.

Currently safe because lines 156-157 pre-default values with || 0, but the function isn't robust standalone. Also consider extracting this to a shared utility to avoid duplication.

Proposed fix

   function fmtBytes(b) {
-    if (!b || b < 1024) return b + ' B';
+    if (!b || b < 1024) return (b || 0) + ' B';
     if (b < 1048576) return (b / 1024).toFixed(1) + ' KB';
     if (b < 1073741824) return (b / 1048576).toFixed(1) + ' MB';
     return (b / 1073741824).toFixed(2) + ' GB';
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/templates/fleet.html` around lines 142 - 147, The fmtBytes function can
produce "undefined B" or "null B" for falsy non-zero inputs; update fmtBytes to
defensively default b to 0 (e.g., treat b as (b || 0)) at the start of the
function so it mirrors fmtNetBytes behavior and never returns "undefined B", and
then consider extracting fmtBytes (and fmtNetBytes) into a shared utility to
remove duplication and keep formatting logic consistent across
app/templates/fleet.html and app/static/js/app.js.

app/static/js/app.js (1)

523-528: Consider adding a visual indicator that CPU/Memory columns show network metrics for Android.

The table headers remain "CPU" and "Memory" (lines 342-343), but Android sub-rows display network TX/RX. Users may be confused seeing byte values in these columns. A small inline label or tooltip on the cells could clarify this.

Otherwise the logic is sound — Android instances correctly show network metrics while non-Android instances retain CPU/memory display.

Also applies to: 532-532, 538-539

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/static/js/app.js` around lines 523 - 528, The CPU/Memory columns show
network metrics for Android instances (inst.is_android) but lack any visual cue;
update the code that builds cpuCell and memCell so when inst.is_android you
append a short inline indicator or tooltip (e.g., " (net TX)" / " (net RX)" or a
span with title attribute) to the displayed fmtNetBytes value, and ensure the
same change is applied where cpuCell/memCell are used (refer to variables
cpuCell, memCell and the inst.is_android branch); keep the existing formatting
for non-Android instances.